VTC media is not encrypted.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-17683	RTS-VTC 1220.00	SV-18857r1_rule	ECCT-1 ECNK-1 ECSC-1	Medium

Description
DoDI 8500.2 IA control ECCT-1 for “Enclave and Computing Environment/Encryption for Confidentiality (Sensitive Data in Transit) states “Unclassified, sensitive data transmitted through a commercial or wireless network are encrypted using NIST-certified cryptography (See also DCSR-2).” [ed. DCSR-2 Specified Robustness – Medium; Type-3]. DoDI 8500.2 IA control ECCT-2 for “Enclave and Computing Environment/Encryption for Confidentiality (Classified Data in Transit) states “Classified data transmitted through a network that is cleared to a lower level than the data being transmitted are separately encrypted using NSA-approved cryptography (See also DCSR-3).” [ed. DCSR-3 Specified Robustness – High; NSA Type-1]. Furthermore, DoDI 8500.2 IA control ECNK-1 for “Enclave and Computing Environment/Encryption for Need-To-Know states “Information in transit through a network at the same classification level, but which must be separated for need-to-know reasons, is encrypted, at a minimum, with NIST-certified cryptography. This is in addition to ECCT. (ed. Encryption for confidentiality data in transit).” DoDI 8500.2 IA control ECCT-2 primarily applies to classified data traversing the IP WAN (i.e., Defense Information Systems Network (DISN)) or other transport media such as a TDM based circuit switched network. The IP WAN is protected by NSA type 1 encryptors that bulk encrypt the circuits or links that interconnect the local classified enclaves or LANs. Separation of traffic for need-to-know purposes, while traversing these classified IP LANs and links, is covered by IA control ECNK-1. On the other hand, Dial-up VTUs that process classified information implement ECCT-2 by utilizing a NSA type 1 encryptor at each VTU and each port of a MCU if applicable. The “NIST-certified cryptography” referred to by these IA controls is cryptography validated to Federal Information Processing Standard (FIPS) 140-2 as validated through the National Institute of Standards (NIST) Cryptographic Module Validation Program (CMVP). In the early days of VTC, CODECs did not support confidentiality of the media or signaling streams directly. As security and conference confidentiality have become an IA issue in recent years, VTU vendors have standardized on DES and AES as encryption standards for VTC media streams. H.235 has been developed to help to secure the signaling protocols used in the H.323 suite of protocols. Most if not all VTC media traffic is considered to be sensitive information requiring protection under the IA controls discussed above. ECNK-1 applies to such traffic while traversing any network with any classification level (e.g., NIPRNet, SIPRNet, JWICS). ECCT-1 specifically applies to such traffic traversing any commercial or wireless network (e.g., Internet, 802.ll WLAN, or cellular network) but should also be considered as a requirement for traversal of the NIPRNet. At minimum, and if supported by both endpoints in a point-to point conference, or all endpoints and the MCU in a multipoint conference, encryption must be used for media encryption. The encryption algorithm required is AES for two reasons. The first is that DES has been cracked and is no longer approved for Federal Government use, and the second is to satisfy DoDI 8500.2 IA control ECCT-1 and ECNK-1; Type-3 encryption of data in transit for confidentiality and need-to-know. Unfortunately, there is a lot of legacy VTC gear in use today that either only supports DES or has no encryption capability at all. To support this situation, newer CODECs typically have three encryption options. ON, OFF, or automatic/negotiate. The preferred setting is ON and should be used if it is known that all other VTUs that a VTU needs to communicate with support encryption. Auto/negotiate is the preferred setting if this is not known. In reality, however, any encryption, AES or DES, is better than no encryption at all and must be used if available. Many VTUs provide the capability to select the type of encryption used and may also provide an auto-negotiate mode. If it is known that all other VTUs that a VTU needs to communicate with uses AES encryption, AES should be selected. DES should never be selected if AES is available. Auto/negotiate is the preferred setting if it is not known which algorithm the other VTUs will use. Note: The sensitivity of conference information is determined by the information owner(s), (that is the organizer and/or the presenting participants in the conference). As such, information owners might decide that their conference information is not sensitive enough to warrant confidentiality through the use of commercial encryption. Even so, encryption should be used and configured if available for those information owners that need to protect their information. Using encryption by default will provide the desired protection for those information owners that need it and will provide additional protection for those that don’t feel it is necessary due to the non sensitive nature of their information.

Description

DoDI 8500.2 IA control ECCT-1 for “Enclave and Computing Environment/Encryption for Confidentiality (Sensitive Data in Transit) states “Unclassified, sensitive data transmitted through a commercial or wireless network are encrypted using NIST-certified cryptography (See also DCSR-2).” [ed. DCSR-2 Specified Robustness – Medium; Type-3]. DoDI 8500.2 IA control ECCT-2 for “Enclave and Computing Environment/Encryption for Confidentiality (Classified Data in Transit) states “Classified data transmitted through a network that is cleared to a lower level than the data being transmitted are separately encrypted using NSA-approved cryptography (See also DCSR-3).” [ed. DCSR-3 Specified Robustness – High; NSA Type-1]. Furthermore, DoDI 8500.2 IA control ECNK-1 for “Enclave and Computing Environment/Encryption for Need-To-Know states “Information in transit through a network at the same classification level, but which must be separated for need-to-know reasons, is encrypted, at a minimum, with NIST-certified cryptography. This is in addition to ECCT. (ed. Encryption for confidentiality data in transit).” DoDI 8500.2 IA control ECCT-2 primarily applies to classified data traversing the IP WAN (i.e., Defense Information Systems Network (DISN)) or other transport media such as a TDM based circuit switched network. The IP WAN is protected by NSA type 1 encryptors that bulk encrypt the circuits or links that interconnect the local classified enclaves or LANs. Separation of traffic for need-to-know purposes, while traversing these classified IP LANs and links, is covered by IA control ECNK-1. On the other hand, Dial-up VTUs that process classified information implement ECCT-2 by utilizing a NSA type 1 encryptor at each VTU and each port of a MCU if applicable. The “NIST-certified cryptography” referred to by these IA controls is cryptography validated to Federal Information Processing Standard (FIPS) 140-2 as validated through the National Institute of Standards (NIST) Cryptographic Module Validation Program (CMVP). In the early days of VTC, CODECs did not support confidentiality of the media or signaling streams directly. As security and conference confidentiality have become an IA issue in recent years, VTU vendors have standardized on DES and AES as encryption standards for VTC media streams. H.235 has been developed to help to secure the signaling protocols used in the H.323 suite of protocols. Most if not all VTC media traffic is considered to be sensitive information requiring protection under the IA controls discussed above. ECNK-1 applies to such traffic while traversing any network with any classification level (e.g., NIPRNet, SIPRNet, JWICS). ECCT-1 specifically applies to such traffic traversing any commercial or wireless network (e.g., Internet, 802.ll WLAN, or cellular network) but should also be considered as a requirement for traversal of the NIPRNet. At minimum, and if supported by both endpoints in a point-to point conference, or all endpoints and the MCU in a multipoint conference, encryption must be used for media encryption. The encryption algorithm required is AES for two reasons. The first is that DES has been cracked and is no longer approved for Federal Government use, and the second is to satisfy DoDI 8500.2 IA control ECCT-1 and ECNK-1; Type-3 encryption of data in transit for confidentiality and need-to-know. Unfortunately, there is a lot of legacy VTC gear in use today that either only supports DES or has no encryption capability at all. To support this situation, newer CODECs typically have three encryption options. ON, OFF, or automatic/negotiate. The preferred setting is ON and should be used if it is known that all other VTUs that a VTU needs to communicate with support encryption. Auto/negotiate is the preferred setting if this is not known. In reality, however, any encryption, AES or DES, is better than no encryption at all and must be used if available. Many VTUs provide the capability to select the type of encryption used and may also provide an auto-negotiate mode. If it is known that all other VTUs that a VTU needs to communicate with uses AES encryption, AES should be selected. DES should never be selected if AES is available. Auto/negotiate is the preferred setting if it is not known which algorithm the other VTUs will use. Note: The sensitivity of conference information is determined by the information owner(s), (that is the organizer and/or the presenting participants in the conference). As such, information owners might decide that their conference information is not sensitive enough to warrant confidentiality through the use of commercial encryption. Even so, encryption should be used and configured if available for those information owners that need to protect their information. Using encryption by default will provide the desired protection for those information owners that need it and will provide additional protection for those that don’t feel it is necessary due to the non sensitive nature of their information.

STIG	Date
Video Teleconference STIG	2014-02-11

Details

Check Text ( C-18953r1_chk )
[IP][ISDN]; Interview the IAO to validate compliance with the following requirement: Ensure the strongest type-3 (commercial grade) encryption algorithm is used to protect all VTC media streams as supported by all communicating VTUs and associated MCUs. Note: It is recognized that legacy devices with which an endpoint might communicate may not support encryption or may only support DES instead of AES as preferred. Therefore the VTU must be configured in such a manner that if AES is available on all communicating VTUs the endpoint will use, or negotiate the use of, AES. If AES is not available on all communicating VTUs the endpoint may negotiate to use DES or no encryption. While the use of DES in lieu of no encryption is preferred, it is not required in this situation unless already supported by the VTU. This is because the use of DES is somewhat better than no encryption at all, even if marginally so. Note: [ISDN] This can be reduced to a CAT III for legacy ISDN/dialup MCU(s) and/or VTU(s) in the event they will not interoperate using native/internal encryption. This is typical between equipment of different vendors. This can be mitigated (and considered not a finding) using external encryption devices as is historically done with secure/non-secure VTC systems. Note: [Classified IP] Understanding that classified IP networks are only protected with NSA type-1 encryption on WAN links between classified enclaves (LANs/CANs); This is not a finding if the VTU is connected to a classified IP network(s) AND conference information owner(s) have determined that the conference information does not require confidentiality or protection for need-to-know from others connected to the same classified network(s) AND conference information owner(s) have provided written confirmation of the decision that encryption is not necessary within the classified enclave (LAN/CAN). Note: [Unclassified IP] Due to the fact that unclassified networks such as NIPRNet connected enclaves (LANs/CANs) are generally accessible to, and able to be compromised from, a public network like the Internet, native encryption is required if supported by the CODEC unless one of the following conditions are met: - The entire VTC system to include endpoints and MCUs are on a physically separate network from the enclave’s general business (or other) LAN with dedicated point-to-point circuits outside the enclave to interconnect to MCUs and other endpoints. In this case, this is “Not a Finding” because the VTC information is protected. - The entire VTC system to include endpoints and MCUs are on a logically separate network on the enclave’s general business (or other) LAN using a dedicated and closed VTC VLAN and protected on the WAN using an encrypted VPN between endpoints directly and/or between endpoints and the MCU. In this case, this is “Not a Finding” because the VTC information is protected. - Every possible user of the VTC system who is an information owner (that is meeting owner/organizer or presenter) designates that their information is publicly releasable or agrees that that their non-public information will not be protected from compromise via the use of encryption. That is conference information owner(s) have provided written confirmation of the decision that encryption is not necessary. In this case, this is a CAT III due to the fact that the VTC information is NOT protected. Note: During APL testing, - This is a CAT I finding in the event the CODEC does not support encryption or it supports DES encryption only. This applies only to new, non-legacy products submitted for testing. - This is a CAT II finding in the event the CODEC does not support auto-negotiation of encryption capabilities and/or the CODEC does not provide a FIPS 140-2 validated encryption module. Determine if the various VTUs with which the system under review is expected to communicate and support Type-3 (commercial grade) encryption and/or the AES algorithm. From this information, determine the appropriate settings required to fulfill the requirement. Have the IAO or SA demonstrate the appropriate settings.

Check Text ( C-18953r1_chk )

[IP][ISDN]; Interview the IAO to validate compliance with the following requirement:

Ensure the strongest type-3 (commercial grade) encryption algorithm is used to protect all VTC media streams as supported by all communicating VTUs and associated MCUs.

Note: It is recognized that legacy devices with which an endpoint might communicate may not support encryption or may only support DES instead of AES as preferred. Therefore the VTU must be configured in such a manner that if AES is available on all communicating VTUs the endpoint will use, or negotiate the use of, AES. If AES is not available on all communicating VTUs the endpoint may negotiate to use DES or no encryption. While the use of DES in lieu of no encryption is preferred, it is not required in this situation unless already supported by the VTU. This is because the use of DES is somewhat better than no encryption at all, even if marginally so.

Note: [ISDN] This can be reduced to a CAT III for legacy ISDN/dialup MCU(s) and/or VTU(s) in the event they will not interoperate using native/internal encryption. This is typical between equipment of different vendors. This can be mitigated (and considered not a finding) using external encryption devices as is historically done with secure/non-secure VTC systems.

Note: [Classified IP] Understanding that classified IP networks are only protected with NSA type-1 encryption on WAN links between classified enclaves (LANs/CANs); This is not a finding if the VTU is connected to a classified IP network(s) AND conference information owner(s) have determined that the conference information does not require confidentiality or protection for need-to-know from others connected to the same classified network(s) AND conference information owner(s) have provided written confirmation of the decision that encryption is not necessary within the classified enclave (LAN/CAN).

Note: [Unclassified IP] Due to the fact that unclassified networks such as NIPRNet connected enclaves (LANs/CANs) are generally accessible to, and able to be compromised from, a public network like the Internet, native encryption is required if supported by the CODEC unless one of the following conditions are met:
- The entire VTC system to include endpoints and MCUs are on a physically separate network from the enclave’s general business (or other) LAN with dedicated point-to-point circuits outside the enclave to interconnect to MCUs and other endpoints. In this case, this is “Not a Finding” because the VTC information is protected.
- The entire VTC system to include endpoints and MCUs are on a logically separate network on the enclave’s general business (or other) LAN using a dedicated and closed VTC VLAN and protected on the WAN using an encrypted VPN between endpoints directly and/or between endpoints and the MCU. In this case, this is “Not a Finding” because the VTC information is protected.
- Every possible user of the VTC system who is an information owner (that is meeting owner/organizer or presenter) designates that their information is publicly releasable or agrees that that their non-public information will not be protected from compromise via the use of encryption. That is conference information owner(s) have provided written confirmation of the decision that encryption is not necessary. In this case, this is a CAT III due to the fact that the VTC information is NOT protected.

Note: During APL testing,
- This is a CAT I finding in the event the CODEC does not support encryption or it supports DES encryption only. This applies only to new, non-legacy products submitted for testing.
- This is a CAT II finding in the event the CODEC does not support auto-negotiation of encryption capabilities and/or the CODEC does not provide a FIPS 140-2 validated encryption module.

Determine if the various VTUs with which the system under review is expected to communicate and support Type-3 (commercial grade) encryption and/or the AES algorithm. From this information, determine the appropriate settings required to fulfill the requirement. Have the IAO or SA demonstrate the appropriate settings.

Fix Text (F-17580r1_fix)
IP][ISDN]; Perform the following tasks: If it is known that all VTUs and MCUs that are expected to communicate support AES encryption; Configure VTUs and MCUs to encrypt media using AES. OR If it is NOT known if all VTUs and MCUs that are expected to communicate support AES encryption; Configure VTUs and MCUs to auto-negotiate encryption capabilities with AES as the preferred method. OR If it is known that all VTUs and MCUs that are expected to communicate cannot be configured to interoperate using encryption: > Implement external (to the CODEC) encryption devices as is done with ISDN only secure/non-secure VTC systems OR > Develop a segregated/dedicated network infrastructure to protect sensitive VTC media (information) OR > Obtain, in writing, a statement from all users of the VTU(s) or MCU(s) that either their information is not sensitive enough to warrant encryption protection for confidentiality and/or need-to-know OR an acknowledgment that they are aware that their sensitive information will not be protected by encryption.

Fix Text (F-17580r1_fix)

IP][ISDN]; Perform the following tasks:

If it is known that all VTUs and MCUs that are expected to communicate support AES encryption; Configure VTUs and MCUs to encrypt media using AES.
OR
If it is NOT known if all VTUs and MCUs that are expected to communicate support AES encryption; Configure VTUs and MCUs to auto-negotiate encryption capabilities with AES as the preferred method.
OR
If it is known that all VTUs and MCUs that are expected to communicate cannot be configured to interoperate using encryption:
> Implement external (to the CODEC) encryption devices as is done with ISDN only secure/non-secure VTC systems
OR
> Develop a segregated/dedicated network infrastructure to protect sensitive VTC media (information)
OR
> Obtain, in writing, a statement from all users of the VTU(s) or MCU(s) that either their information is not sensitive enough to warrant encryption protection for confidentiality and/or need-to-know OR an acknowledgment that they are aware that their sensitive information will not be protected by encryption.